Benchmark Results

What a performance boost! 🚀

I dug a bit on why this change made such a difference, resulting on this compile time assertion here.

The bottom line is: the imbl crate have optimizations that are well suited for small values, often holding them in the stack before creating their internal heap-allocated trees. Previously, Value had a size of 72 bytes in the stack, which forces imbl to start allocating on the heap soon and often. Now the size of Value is 8 bytes, which makes more use of imbl inline stack allocation.

As an experiment, I've replaced the use of ImmutableVec in Value::Tuple with a simple Rust Vec instead and that change alone gives a boost of ~60%:

main:
tuples/rust             time:   [3.8570 s 3.8728 s 3.8897 s]

main (tuples are vectors):
tuples/rust             time:   [1.5432 s 1.5706 s 1.5993 s]
                        change: [-60.113% -59.445% -58.736%] (p = 0.00 < 0.05)
                        Performance has improved.

This serves as further confirmation that imbl was indeed struggling to host values before.

It's worth noting that this patch also promotes some degree of memory fragmentation as simple values like integers (that are cheap to copy) are no longer stack allocated and will get scattered around the heap a lot. However, quint specs aren't as long lived as real programs so, my intuition is that this fragmentation won't impact us that much.

This is all worth considering as we work on this data structures in future iterations of the rust backend, though.

Interesting. Switching from native data structures to immutable ones (from imbl) was a huge performance boost when we had the very first version of the rust evaluator. Let's discuss this next week.

After discussing in the meeting, this makes more sense. From what Erick explained, I understood that it could be benefitial to move smaller data structures like tuples from imbl to native vectors due to allocation speed, as tuples won't "grow" over time (growing as in making copies of it with more elements).

@erickpintor I think we are good to merge. You can approve (I can't as I'm the author) and merge it whenever you like

Sounds good!